1. Technical Field
The present invention relates generally to computer processing systems and, in particular, to methods for extracting reference patterns in JAVA and depicting the same. The extracted and depicted reference patterns may be used to explore data structures in JAVA, as well as to identify and solve memory leaks.
2. Background Description
Complexity in software systems is still growing significantly. Modern languages like JAVA take away some of the burden of memory management by offering automatic garbage collection. In languages having garbage collection, a garbage collector periodically frees all the objects that can no longer be xe2x80x9creachedxe2x80x9d from the running program. For articles describing garbage collection in software languages, see xe2x80x9cUniprocessor Garbage Collection Techniquesxe2x80x9d, P. Wilson, Proceedings of the International Workshop on Memory Management, St. Malo, France (September 1992), Lecture Notes in Computer Science, Vol. 637, pp. 1-42, Springer-Verlag (1992); and xe2x80x9cGarbage Collectionxe2x80x9d, Jones et al., John Wiley and Sons (1996).
Garbage collection, however, can be a double-edged sword. Programmers may get the false impression that they don""t have to worry about memory when using a garbage-collected language. Unfortunately, many JAVA programs run out of memory unexpectedly after performing a number of operations. Quite often, this is the result of what is referred to as a memory leak. In JAVA, a memory leak is caused when a first object cannot be reclaimed because another object is still unintentionally referring to the first object, even though the first object is no longer needed. Memory leaks can be difficult to solve, since the complexity of most programs prevents us from manually verifying the validity of every reference. Thus, even in JAVA, programmers need a way to identify leaking objects, and to tackle the more difficult task of discovering who is holding on to these objects and why.
Memory leaks often occur according to a simple scenario, which will now be described. In the scenario, there is a self-contained operation (for example, the display of a temporary dialog window) in which temporary objects are created, as shown in FIG. 1. By the end of the operation (in this example when the dialog window is closed) we expect all of these temporary objects to be released. Only some, however, are actually released. Many programs with memory leaks fit this pattern in one way or another.
A program reaches a stable state; its object population 102 is shown in the lower area in the figure. Then we perform a temporary operation such as, for example, opening a dialog window. The new objects 104 allocated for this operation are shown in the upper area. When the user closes the window, the program will typically set the reference 106 between the old objects (lower view) and the new objects (upper view) to null. Ideally, the next garbage collection will then clean up all the new objects which were associated with the window.
What happens very often, however, is that during such a temporary operation, other old objects may get to know about some of the new objects. This situation is shown in FIG. 2, which is a diagram illustrating memory leaks caused by vestigial references. A typical case is a registry 202 (in the lower area of the figure) that acquires a reference 204 to a new object 206. The programmer may not be aware of this hidden reference, and fail to set this reference to null at the end of the operation. As a result the garbage collector will not reclaim some objects that were meant to be collected after the temporary operation has finished.
Even when we have identified leaking objects and references to them, some further exploration will usually be required by the programmer in order to fully understand the results. For example, the programmer may want to dig deeper and understand why an object was created in the first place, or distinguish true leaks from artifacts like cached objects which are retained intentionally. Searching through individual object references is not practical in anything but the simplest program, given the large number of objects and the richness of their interconnections in most programs.
Accordingly, it would be desirable and highly advantageous to have methods for extracting reference patterns in JAVA and depicting the same. Moreover, it would be desirable and highly advantageous to have a method for exploring data structures. Further, it would be desirable and highly advantageous to have methods for identifying and solving memory leaks in JAVA, as well as distinguishing true memory leaks from artifacts (e.g., cached objects) which are retained intentionally.
The present invention is directed to methods for extracting reference patterns in JAVA and depicting the same. The extracted and depicted reference patterns may be used to interactively and selectively explore data structures, identify and solve memory leaks, and distinguish true memory leaks from artifacts.
In one aspect of the present invention, a method for extracting reference relationships among objects corresponding to a running program includes the step of designating a starting set of objects. The starting set of objects is partitioned into subsets of objects grouped by class. A recursive operation is applied to each of the starting subsets. The recursive operation includes the step of, given a subset of objects, identifying a second set of objects. The second set includes all objects that refer to at least one object in the subset when a direction of reference terminates at the starting set. Alternatively, the second set includes all objects that are referred to by at least one object in the subset when the direction of reference originates from the starting set. The recursive operation also includes the step of partitioning the second set into new subsets of objects grouped by class. The recursive operation is applied to each of the new subsets until a predefined depth is reached.
In another aspect of the present invention, a method for representing relationships among objects corresponding to a running program includes the step of representing a reference between a first set of objects grouped by class and a second set of objects grouped by class using a first visual syntax, when each of the objects in the second set refer to at least one object in the first set. A direction of the reference between the first and second sets is represented using a second visual syntax.
In yet another aspect of the present invention, a method for displaying references to leaking objects corresponding to a temporary operation in a running program includes the step of inventorying a first set of objects corresponding to objects in an object heap at a point in time preceding the performance of the temporary operation, a second set of objects corresponding to objects in the object heap at a point in time following the performance of the temporary operation, references between the objects of the second set, and references starting from non-JAVA sources to the objects of the second set. Identifiers associated with the objects in the first set of objects are compared to identifiers associated with the objects in the second set of objects to identify a third set of objects corresponding to the objects in the second set of objects that are not in the first set of objects. The references to the objects in the third set of objects are displayed.
These and other aspects, features and advantages of the present invention will become apparent from the following detailed description of preferred embodiments, which is to be read in connection with the accompanying drawings.